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ABSTRACT 

The categorical notion of monad, used by Moggi to structure 
denotational descriptions, has proved to be a powerful tool 
for structuring combinator libraries. Moreover, the monadic 
programming style provides a convenient syntax for many 
kinds of computation, so that each library defines a new 
sublanguage. 

Recently, several workers have proposed a generalization 
of monads, called variously “arrows” or Freyd-categories. 
The extra generality promises to increase the power, ex¬ 
pressiveness and efficiency of the embedded approach, but 
does not mesh as well with the native abstraction and appli¬ 
cation. Definitions are typically given in a point-free style, 
which is useful for proving general properties, but can be 
awkward for programming specific instances. 

In this paper we define a simple extension to the functional 
language Haskell that makes these new notions of computa¬ 
tion more convenient to use. Our language is similar to the 
monadic style, and has similar reasoning properties. More¬ 
over, it is extensible, in the sense that new combining forms 
can be defined as expressions in the host language. 

1. INTRODUCTION 

A useful method for implementing of domain-specific lan¬ 
guages (DSLs) is to embed them in a general-purpose lan¬ 
guage. Functional languages are particularly suitable, as 
originally noted by Landin [19] and widely exploited since. 
Hudak [11] gives a recent account. 

Many of these libraries or sublanguages have a common 
structure; they involve a monad, a categorical structure that 
Moggi applied to the structuring of denotational descrip¬ 
tions [22] and Wadler subsequently applied to functional 
programming [30]. Much useful code can be written to the 
monad abstraction, and is thus useful with each such library. 

In the monad-based view of computation [22], we move 
from expressions yielding values of type A to computations 
of type M A, where M is a functor with certain operations. 
A simple example of the monadic style of programming is 
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the following Haskell [24] function that adds the results of 
two computations: 

addM :: Monad m=$> m Int —* m Int —* m Int 
u ‘addM 1 v = u »= Xx —> 
v >= Xy -> 
return (x + y) 

Though the setting is more general, variables like x and y 
still denote values, and may be bound using Haskell’s A- 
abstraction. 

A neat example of a monad-based library is provided by 
recursive-descent parsers [13]. One can write a set of mu¬ 
tually recursive computations that closely mirror the origi¬ 
nal grammar, subject to the usual limitations of top-down 
parsing. However such parsers have a major flaw: they 
are typically designed to backtrack on error, which is both 
inefficient and makes useful error reporting very difficult. 
The deterministic parsing library designed by Swierstra and 
Duponcheel [28] solves these problems, but steps beyond 
the world of monads. The reason is the same as the source 
of the efficiency of this technique: the parser has a static 
component that is independent of the input, and this would 
be lost in any definition of the >= combinator. Moreover, 
as they noted, this optimization technique is applicable in 
many other contexts, but the resulting libraries would not 
be monadic. 

Hughes [12] showed that monads could be generalized to 
“arrows” relating inputs and outputs. Workers in denota¬ 
tional semantics have proposed similar frameworks [4, 26, 
27]. Such arrows may represent “procedures” that have a 
static component independent of the input, or other kinds 
of procedure that accept multiple inputs, as well as monadic 
computations. The added generality is useful, but comes at 
a cost: since procedures are no longer functions, they cannot 
be manipulated using the abstraction and application fea¬ 
tures of the underlying language. One can use a point-free 
style resembling category theory, which is very convenient 
for proving general properties, but can be awkward for pro¬ 
gramming specific instances. 

The contribution of this paper is to define a convenient 
notation for computation corresponding to these semantic 
notions, designed as an extension to the functional language 
Haskell [24]. Although arrows cannot in general be factored 
as functions, we are able to define limited forms of applica¬ 
tion and abstraction, as well as a notion of control operator 
for combining arrow-based computations. We also extend a 
notion of feedback to arrows to support recursion. The new 
constructs are defined by translation to standard Haskell. 

The rest of the paper is organized as follows. In the next 
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Figure 1: Arrow equations 


section we briefly review Hughes’s arrows. Section 3 presents 
our proposed extension to Haskell, illustrated using an ex¬ 
ample from [12]. A larger example, an embedded language 
for regular data parallel algorithms, is described in Section 4. 
In Section 5 we consider how arrows may be extended to al¬ 
low recursive definition of values, and similarly extend our 
syntax. This extension is applied in our final example, an 
embedded language for circuit description, in Section 6. 

Although our focus is on programming, many of the con¬ 
cepts here are inspired by category theory. Short discussions 
of the connections are given in subsections entitled Theoret¬ 
ical Aside. These may be useful to readers with the appro¬ 
priate theoretical background, but they are not essential to 
the main development. 

The extension to Haskell described here has been imple¬ 
mented by a preprocessor that produces Haskell 98. The 
preprocessor is itself written in Haskell 98, as an extension 
of a Haskell parser and pretty printer written by Sven Panne, 
Simon Marlow and Keith Wansborough. This paper was for¬ 
matted from a literate script which has also been fed to the 
preprocessor, and thence to Haskell implementations. 

2. ARROWS 

We briefly recall Hughes’s definitions from [12]. 

Definition 1. An arrow type is a binary type constructor 
a with the following data: 

class Arrow a where 

arr :: (b -► c) -> a b c 

first:: ab c^ a(b,d) (c, d) 

satisfying the equations of Figure 1. The functions (x) and 
assoc used there are defined as follows: 

(x) :: (a —» a') —►(&—> b') —* (a, b) —> (a', b') 

(/x g) (a,b) = (f a, g b) 

assoc :: ((a, b), c) —> (a, (b, c)) 
assoc ((a, b),c) = (a,(b,c)) 

There is no need to require a second function, as it is 
defined in terms of first: 

second :: Arrow a => a b c —> a (d, b) (d, c ) 
second f = arr swap first f arr swap 

swap :: (a, b ) —► ( b , a) 
swap~(x,y) = (y,x) 


The following definitions will also be useful: 

(**) :: Arrow a => a b c —> a b'd —> a (b,b') (c, c') 
f m g = first f second g 

(Me) :: Arrow a => a b c —> a b d —> a b (c, c') 
f Mi g= arr (Xb ^ (b , b)) f m g 

Note that ** does not in general preserve composition; for 
example, the order in which effects occur is significant. 
Ordinary functions are a special case 

instance Arrow (—*•) where 
arr f = f 
f^>g = gf 
first f = f x id 

The Kleisli arrows of a monad may also be cast as an arrow 
type. 

newtype Kleisli m a b = K (a —> m b) 

instance Monad m => Arrow (Kleisli m) where 
arr f = K (return • /) 

K f K g = K (Xb —> f b g) 
first (K f) = K (A (b, d)^fb^= Ac ^ 
return (c, d)) 

However, there are other important examples, as we shall 
see later. 

Some arrow types have additional constants. Hughes gave 
a class specifying an application operator 

class Arrow a => ArrowApply a where 
app :: a (a b c, b) c 

which is required to satisfy certain conditions [12]. The triv¬ 
ial arrow type —> and Kleisli arrow types satisfy these con¬ 
ditions, and indeed any such arrow type is equivalent to a 
Kleisli arrow type [12, 27]. 

Hughes also defined structures on sum types dualizing 
those on product types: 

class Arrow a =4> ArrowChoice a where 

left:: a b c —*• a (Either b d) (Either c d) 

right:: ArrowChoice a => 

a b c —> a (Either d b) (Either d c) 
right f = arr mirror left f 'M> arr mirror 
where mirror (Left x) = Right x 
mirror (Right y) = Left y 

(-H-I-) :: ArrowChoice a =$■ 

abc-^ab'c'^a (Either b b') (Either c c') 

/ -m- g = left f right g 

(HI) :: ArrowChoice a 

abd—>acd—>a (Either b c) d 
f HI g =f +H- g^> arr untag 

where untag (Left x) id x 
untag (Right y) = y 

As an illustration of the programming style used with ar¬ 
rows, here is an arrow operation corresponding to addM 
from the previous section: 

addA :: Arrow a => a b Int —> a b Int —> a b Int 
addA f g = f Me g arr (A(a:, y) —> x + y) 





2.1 Theoretical Aside 

Similar structures have been independently proposed by 
workers in denotational semantics. We give here a simpli¬ 
fied (but equivalent) version of a definition of Power and 
Thielecke [27]. 

Definition 2. A Freyd-category consists of 

• a category V with finite products (the value category), 

• a category C with the same objects as V (the compu¬ 
tation category), 

• a functor inc : V —♦ C that is the identity on objects, 

• a functor x : C x V —> C such that 


inc x K y = inc (x x y) 
and the following natural isomorphisms in V 
assoc x : (A x B) x C = A x (B x C) 
unitr x : Axl^A 
extend to natural isomorphisms in C: 

inc assocx : (A x B) x C ^ A x (B x C) 
inc unitr x A K 1 = A 


data Expr = Plus Expr Expr \ Minus Expr Expr \ ■ ■ ■ 

expr :: ParseArrow () Expr 
expr = term exprTail 


exprTail :: ParseArrow Expr Expr 
exprTail — ( 

arr (Ae —> (e, ())) » 
second (symbol PLUS ) 
second term 

arr (A(e, t) —> Plus e t) ^ 
exprTail 




r{ Ae-(e,()))» 
second (symbol MINUS) ^ 
second term 

arr (A(e, t) —> Minus e t) 3 
exprTail 
rr id 


term :: ParseArrow () Frrpr 


Figure 2: Expression parser using arrows 


The first four of Hughes’s axioms correspond to the re¬ 
quirements of a category C and an object-preserving functor 
inc (corresponding to arr). Hughes’s first corresponds to the 
family of functors — K C for each object C, with the last two 
of his axioms corresponding to the naturality requirements 
above. 

In this form, the definition is easily generalized to any 
symmetric monoidal category. Nor is the assumption of 
symmetry required; one merely assumes two bifunctors and 
additional axioms, obtaining what Power and Robinson call 
a notion of computation [26]. Even more general structures 
have been explored by Blute, Cockett and Seely [4]. 

Hughes [12] showed that the stream processors of the Fud- 
gets library [5] comprised an arrow type, but were more often 
used as a dual arrow type. In Power and Robinson’s terms, 
stream processors comprise a notion of computation where 
the underlying monoidal structure is that of sums rather 
than products. 

A Freyd-category is said to be closed [27] if each functor 
inc - x A : V — > C has a right adjoint; this is equivalent to 
Hughes’s ArrowApply class. 

2.2 Deterministic Parsing 

Hughes showed how Swierstra and Duponcheel’s parser li¬ 
brary may be recast using an arrow type, say ParseArrow , 
with composition corresponding to grammatical concatena¬ 
tion. For the empty language and union, we use the classes 

class Arrow a => ArrowZe.ro a where 
zero Arrow :: a b c 

class ArrowZe.ro a => ArrowPlus a where 
(<$>) ::abc^abc-rabc 

which make sense for many kinds of arrow. An extra prim¬ 
itive is supplied for terminal symbols. 

symbol :: Sym —> ParseArrow () () 


Now we can write parsers using arrow combinators. For 
example, the parser in Figure 2 expresses the common ex¬ 
ample grammar 

expr term exprTail 

exprTail ::= PLUS term exprTail 
| MINUS term exprTail 

I $ 

In this program the underlying grammar is obscured by all 
the plumbing required to pass the results of earlier computa¬ 
tions past later ones. (Indeed this is the reason for requiring 
first in the arrow definition.) This point-free style is typical 
of arrow-based programs. While convenient when defining 
general combinators and laws, it can be very cumbersome 
for specific definitions. 

3. ARROW-BASED SUBLANGUAGES 

We propose to address this problem by defining an ex¬ 
tension to Haskell, with the meaning of new forms given by 
translation rules from the new expressions back into Haskell. 
This will be done in two stages. Firstly we define a syntax for 
arrow expressions, which will enable us to write programs re¬ 
sembling the raw monadic syntax (using >= and ;#>■). Then 
on top of this we will define an analogue of Haskell’s do- 
notation. 

The new syntax for arrow expressions, with associated 
translation rules, is given in Figure 3. An arrow expression 
is defined by a new binding operator proc. The body of 
such an expression is a new form, which we call a command. 

3.1 Arrow Application 

The simplest kind of command is the arrow application 
ei —< e2, where e2 is a Haskell expression to be input to 
the arrow described by the Haskell expression ei. As noted 
above, there is in general no notion of application of arrows, 





expression like 


Syntax 


| proc pat —^ cmd 

cmd ::= exp —< exp 

| form exp cmdi ... cmd n 
| cmd i op cmd2 
| Kpat —> cmd 
j (cmd) 


Translation rules 

proc p —> ei —< e2 

proc p —> form e ci 

proc p —* ci op c 2 
proc p-tsp'-tc 


arr (Ap -> e 2 ) ei 
if Vars(p) fl Vars(ei) = 0 
arr (Ap -> (ei, e 2 )) app 
otherwise 


(proc p —> ci) ... (proc p -> c„) 
proc p —> form (op) Ci c 2 
proc (p,p') —» c 


Figure 3: Arrow expressions 


but the rule allows two useful special cases. The first is 
proc p —> ei —< e 2 = arr (Ap —► e 2 ) ei 

Clearly this is meaningful only if ei contains no variables 
defined in p. A simple example of an expression for ei is the 
identity arrow 

returnA :: Arrow a => a b b 
retumA = arr id 

Then we have 

proc p —> returnA —< e = arr (Ap —> e) 

This arrow returnA will play a role analogous to return in 
monad notation. 

The second translation is 

proc p -> ei —< e 2 = arr (Ap -*• (ei, e 2 )) app 

This version has no such syntactic restriction, but it does 
require that the arrow in use belong to the class ArrowApply , 
and thus be equivalent to a monad. Thus both rules are 
needed. The rules overlap, but from the axioms of app it is 
possible to show that in that case they produce equivalent 
translations. 

Hence we must distinguish two kinds of variables: 
local variables defined in the current arrow expression, 
external variables defined outside. 

In this paper we shall focus on arrows that are not equiv¬ 
alent to monads, so we shall use only the first form of arrow 
application. Nevertheless, the notation may be used with a 
variety of arrows, some of which are equivalent to monads. 

3.2 Control Operators 

Next we need a means to combine commands to make new 
ones. In the monad setting, we have operators like 

mplus :: MonadPlus m=>ma—>ma—>ma 


This works well, because in an 
ei ‘mplus 1 ei 

the two expressions may take inputs from environment vari¬ 
ables bound in ordinary ways. However, we cannot in gen¬ 
eral factor an arrow type as a function from inputs, so an 
arrow combinator must route the inputs of the composite ex¬ 
pression to each of the arguments. Hence the corresponding 
arrow operator has the signature 

(<$>) :: ArrowPlus a^>abc—>abc—>abc 
In the arrow notation, a command describes an arrow from 
the local environment. We can use operators to combine 
commands by combining the resulting arrows, so for example 

proc p —> ci <$> ci = (proc p —> ci) <S£> (proc p —> c 2 ) 
In general an operator may be an arbitrarily complex Haskell 
expression meeting certain conditions (to be given below). 
The syntax requires a keyword form to distinguish these 
from commands. However in the special case of infix oper¬ 
ators we can use an abbreviated syntax as above. 

Parameter Passing. Some operators pass data to their ar¬ 
guments. For example, the monadic operator for exception 
handling has the form 

handle :: MonadHandle ex m => 

If the second argument (the handler) is called, it is passed 
the exception raised. The arrow form will also have two 
arguments. Each will be passed the input, with the second 
also being given the exception: 

handleA :: ArrowHandle ex a => 

abc^a(b,ex)c^abc 

We shall adopt the convention of adding argument data by 
pairing in this way. In general the input of an arrow will 
have the form 

((...(«),...),0 

where v is the original input, named by the proc pattern 
p, and the Vi are additional arguments, as yet unnamed. 
The next form, the k quantifier, applies another pattern 
to the innermost argument ui within a sub-command. A 
similar quantifier occurs in the abstract machine framework 
of Douence and Fradet [7], transferring a value from the 
argument stack to the environment. 

Thus we can write a command like 
ci ‘ handleA ‘ n ex —> c 2 

This may be read just like the corresponding monadic form: 
the body ci is executed, and if it raises an exception then 
the handler c 2 is called, with ex bound to the exception 
raised. However, the arrow version of the operator passes 
the original environment to both commands, as we can see 
from the translation: 

proc p —> ci ‘ handleA ‘ n ex —> c 2 
= (proc p —> ci) ‘ handleA ‘ (proc p —> k ex —> c 2 ) 

= (proc p —> ci) ‘handleA ‘ (proc (p, ex) —> c 2 ) 

An operator may also accept an argument from its caller in 
a similar way, as in the following operator to encapsulate 
state-transforming arrows: 

runWithState :: ... =>■ a b c —> a' (b,0) e 




Naturality. We stated above that an operator delivers in¬ 
puts of the composite arrow to its components. We can 
formalize this with a naturality condition for each opera¬ 
tor. For example, the handleA operator will be required to 
satisfy 

arr k (/ ‘handleA‘ g) = 

(arr k^> f) ‘handleA‘ (arr (k x id) g) 

This ensures that inputs delivered by the operator to / or 
g were inputs to the whole expression. In general, an input 
to the whole expression need not be delivered to each argu¬ 
ment; in the above example g is called only if an exception 
occurs in /. But any input that is delivered must have been 
an input to the whole arrow. 

In the special case of a Kleisli arrow of a monad m, this 
naturality condition ensures that the operator is equivalent 
to a monadic operator. In this case, the type of handleA is 
equivalent to 

(b^mc)^ ( (6 , ex) _> m c) - b m c 
Currying the second argument gives the type 
{b —> m c) —>■ (& —► ex —► m c) —> b —► m c 

Since this is natural in b (and the Kleisli arrows factor as 
functions) it is equivalent to the type of the corresponding 
monad operator 

Many monadic operators have similar generalizations in the 
arrow setting. 

Formal Definition of a Control Operator. In order to 
specify which Haskell expressions may serve as control op¬ 
erators, we need a preliminary definition: 

Definition 3. Let r stand for a Haskell value type. We 
introduce a new sort of types 

Command types 9 ::= a\r | r —>■ 9 

For each Haskell type r and command type 9, we define a 
Haskell type r 9 as follows 

r 'yfe a\r' = arr' 

If k :: n —> T2, we can define a function k^ 9 :: (t 2 9) —> 

(n 9) by 

/r ~ (t ->• 9) « {k x id) — 0 

Definition 4- A Haskell expression e is a control operator 
of signature 9i —► • • • 9„ —► 9 if 

1. No local variables occur free in e, 

2. e has type 

V6. -► • • • (6 0„) -> 9) 

where b does not occur free in any of the 9s, and 

3. e satisfies a corresponding naturality property 

e ((*~>0i) Xl) ... ((k^9n) Xn) = 

(k^9) (e xi ... Xn) 


expr :: ParseArrow () Expr 
expr = proc () —> 

(term —< ()) ‘bind ‘ n t — > 
expr Tail —< t 

exprTail :: ParseArrow Expr Expr 
expr Tail = proc e —> ( 

(symbol PLUS -< ())‘bindJ 
(term —< ()) l bind‘ k t —> 
exprTail —< Plus e t 

) <+> ( 

(.symbol MINUS -< ())‘bindJ 
(term —< ()) l bind‘ k t —> 
exprTail —< Minus e t 
) <$> (retumA —< e) 


Figure 4: Expression parser in arrow notation 


The first two conditions would be checked by the imple¬ 
mentation. It may be that the naturality property can be 
obtained automatically from parametricity results. 

For example, the control operator handleA has signature 
a\c -*■ (ex a\c) -*• a\c. 

Examples. Some functions we have already seen are also 
examples of control operators: 

(Me) :: Arrow a=>abc^abd—>ab(c,d) 

(<$>) :: ArrowPlus a a b c —* ab c—> a b c 
zero Arrow :: ArrowZero a => a b c 

Others may be defined using the features of Haskell. For 
example, the arrow counterpart of the monadic binding op¬ 
erator may be defined as 

bind :: Arrow a=>abc—>a(b,c)d—>abd 

Using this operator, we can redefine addA (which is also an 
operator): 

addA :: Arrow a => a b Int —> a b Int —> a b Int 
addA f g = proc z —> 

(/ —< z) ‘bind 1 kx —> 

(g —< z) ‘bind 1 n y — > 
retumA —< x + y 

Another useful operator is the special case of bind where the 
result of the first computation is ignored, corresponding to 
the monadic >- combinator: 

bind _ :: Arrow a=>abc—>abd—>abd 
u ‘bindv = u ‘bind 1 (arr fst ;§> v) 

Now we can rewrite the arrow parser of Figure 2, obtaining 
the version of Figure 4. As promised, the form of this pro¬ 
gram is very similar to what we would write with monadic 
parser combinators [13]. The point is that this program 
works not merely for monadic parsers but also for any parser 
that can be cast in the more general arrow form, including 
the optimized ones of Swierstra and Duponcheel [28]. All 
the plumbing of the previous version is hidden. 




3.3 Theoretical Aside 

Power and Thielecke [27] showed that each Freyd-category 
is equivalent to a kind of indexed category called a K-category. 
Each category Ha models computations in a context A, and 
has the same objects as C, with morphism sets 
H a {B, C) = C(A x B,C) 

Our command sublanguage could be viewed as a language 
for such indexed categories, with A corresponding to the in¬ 
put context and B to additional arguments. The k quantifier 
then corresponds to the obvious isomorphism 
H a {B x C,D) = H A xb(C, D) 
as in Hasegawa’s K-calculus [9]. A control operator defines a 
natural family of functions, one for each category Ha- These 
generalize the controls of elementary control structures [25], 
which are used to model concurrency. Our definition sug¬ 
gests a higher-order generalization, although such operators 
appear to be less useful. 

3.4 Type-checking of Commands 

One could use the equations of Figure 3 to transform any 
arrow expression into ordinary Haskell, where it will be type- 
checked, but it would obviously be easier for users to deal 
with a type system for the command sublanguage. There 
is not room here for a formal treatment, not least because 
there is no complete definition of Haskell’s type system to 
refer to, but the basic ideas are simple. Each command is 
assigned a command type as follows: 

• If ei :: a t t' and ei :: r, then ei —< ei has type a\r'. 

• If c has type 9 assuming p :: r, then np —> c has type 
t^9. 

• If each a has type 9i and e is a control operator of 
signature 9 1 —> ■ ■ ■ 9 n —*- 9, then form e ci ... c„ has 
type 9. 

It follows (by induction on c) that if c has type 9 assuming 
p :: r, then proc p —> c :: r 9, and 

((A p —> e) 9) (proc p —> c) = proc p —> [e/p]c 
This equation expresses the naturality of commands with 
respect to the environment, allowing us to change the rep¬ 
resentation of the environment, for example to improve effi¬ 
ciency. We shall return to this point in Section 3.7. 

3.5 Equivalences 

It is also useful to reason directly with commands. 

Definition 5. We write ci = p C2 for 



3.6 do-notation for Arrows 

We can take the correspondence further, by defining a 
do-notation for commands in a similar fashion to Haskell’s 
monadic do-notation. The syntax and translation rules are 
given in Figure 5. The rec construct, which allows recursive 
bindings, will be discussed in Section 5.3. 

Then the above operator addA could be rewritten as 

addA :: Arrow a => a b Int —> a b Int —> a b Int 
addA f g = proc 2 —> do 
x^f-<z 
y^g-<z 


proc p —> ci = proc p —> C2 
and ci = C2 to mean ci = p ci for all legal p. 

Then we have the following equivalences for retumA and 
bind, corresponding to the familiar monad laws: 

(retumA —< e) ‘ bind‘ m-»c e [e/a:]c 
c ‘ bind ‘ ks: -> retumA —< x = c 
ci ‘bind‘ Mi -> (02 ‘bind‘ k® -> C3) e 

(ci ‘bind 1 kxi —> C2) ‘bind 1 kxi —> C3 
An arrow library would typically supply a collection of ar¬ 
rows and operators with associated laws, ideally expressed 
as equivalences between commands. 


Similarly, the parser example of Figures 2 and 4 may be 
rewritten as in Figure 6, which is similar to the monadic 
version, though it works for a wider variety of parsers. 

3.7 Improving the Translation 

The rules of Figures 3 and 5 define the meaning of the new 
constructs in clear way, but may produce less efficient pro¬ 
grams than one might have written by hand. For example, 
the arrow addA above would be translated to 

= arr id 

arr id «z (arr (A {z,x) -► 2) 3) 

arr (A {(z,x), y) -*• x + y) 


addA f g 





Note that both the original input z and the first result x 
are held during the computation of g, even though z is not 
required. We can project out z when it is no longer needed, 
obtaining the improved version 

addA f g = arr id ffiz / 

arr (A (z, x) —> ( x , z )) ;§> second g ;§> 
arr (A (x,y) -*• x + y) 

which is essentially equivalent to what we would write by 
hand. These projections may also be moved through oper¬ 
ators, thanks to their naturality property. The prototype 
implementation incorporates many such improvements. 

4. EXAMPLE: DATA PARALLELISM 

For each set S, the type a s —> b s defines an arrow. Such 
arrows may be used to model data parallel computation; 
here S represents the set of processors, and the arr oper¬ 
ation executes the same function on each processor. Addi¬ 
tional combinators will be required for the various opera¬ 
tions supported by a particular model. 

Here we shall focus on a special case: algorithms operat¬ 
ing on 2 n elements, whose behaviour is defined by induction 
on n. These arise in circuit design (cf. Ruby [15]), and de¬ 
scriptions of parallel algorithms (cf. Misra’s powerlists [21]). 

The objects of interest then consist of infinite sequences 
of functions on arrays of increasing size 

We can model a 2 as Pair n a, where 
type Pair a = (a, a) 

Thus the elements are organized as a perfectly balanced bi¬ 
nary tree of depth n, and we are interested in functions that 
preserve this depth. We call them “homogeneous functions” 
and model them with the following Haskell datatype: 

data Horn a b = (a —> b) :&: Horn (Pair a) (Pair b) 
Elements of this type have the form 

fo :&: fi h :&:... 
where f n ■■ Pair n a —> Pair n b. 

Before writing programs with this datatype, we need a 
framework for executing them. We will define a type for 
perfectly balanced binary trees: 

data BalTree a = Zero a \ Succ (BalTree (Pair a)) 
deriving Show 

Here are some example elements: 

treeO = Zero 1 

treel = Succ (Zero (1, 2)) 

tree2 = Succ ( Succ ( Zero ((1, 2), (3,4)))) 

tree3 = Succ (Succ (Succ (Zero (((1, 2), (3,4)), 

((5,6), (7,8)))))) 

The elements of this type have a string of constructors ex¬ 
pressing a depth n as a Peano numeral, enclosing a nested 
pair tree of 2 n elements. 

The following function applies a homogeneous function 
to a perfectly balanced tree, yielding another perfectly bal¬ 
anced tree of the same depth: 


apply :: Horn a b —> BalTree a —> BalTree b 
apply (/ :&:/s) (Zero x) = Zero (/ x) 
apply (f :&r.fs) (Succ t) — Succ (apply fs t) 

Few other operations can be expressed in terms of the bal¬ 
anced tree type. Typically one wants to split a tree into two 
subtrees, do some processing on the subtrees and combine 
the results. But the type system cannot discover that the 
two results are of the same depth (and thus combinable). 
Of course, this is exactly what homogeneous functions can 
do, so we shall focus on them; the balanced tree type is used 
only for test runs of our algorithms. 

Firstly, Horn is an arrow: 

instance Arrow Horn where 
arr f = f :&: arr (/ x /) 

(/:&:/«) (g :&z:gs ) = (g ■ f) :&z:(fs gs) 

first (/ :&: fs) = first f :&: 

(arr transpose first fs arr transpose) 

transpose :: ((a, b), (c, d)) —> ((a, c), (&, d)) 
transpose ((a, b), (c, d)) = ((a, c), (&, d)) 

The function arr maps a function over the leaves of the 
tree. The composition composes sequences of functions 
pairwise. The ** operator unriffles a tree of pairs (a, b) into 
a tree of as and a tree of &s, applies the appropriate function 
to each tree and riffles the results. 

When describing algorithms, one often provides a pure 
function for the base case (trees of one element) and a ex¬ 
pression for trees of pairs, usually invoking the same algo¬ 
rithm on smaller trees. 

Parallel Prefix. This operation (also called scan) maps the 
sequence 

*0,21,2:2, ■ • . ,* 2»—1 

to the sequence 

*0, *0 ® *1,2:0 © *1 © *2, • • • , 2:0 © *1 © • • • © 2:2"-l 
for some associative operation ®. 

If there is only one element (i.e. the tree has zero depth) 
then obviously the scan should be the identity function. 
Otherwise, we need to deal with a tree of pairs, so the gen¬ 
eral scan operation will have the form 

scan :: (a —> a —> a) —> a —► Horn a a 
scan (®) b = id :&: proc (2:,y) 

where b is the identity of the ® operation 1 . The missing part 
will be defined using recursive calls of scan, but operating 
on smaller trees. 

An efficient scheme, devised by Ladner and Fischer [18], 
is first to sum the elements pairwise: 

2:0 ® 2:1,2:2 ® 2:3, X4 ® 2:5,... 

and then to compute the scan of this list (which is half the 
length of the original), yielding 

2:0 ® 2:1,2:0 ® 2:1 ©,%- .© 2:3,2:0 ffi 251 ffi 2:2 © X3 © X4 © X5, . . . 
This list is half of the desired answer; the other elements are 
2:0,2:0 © 2:1 © 2:2,2:0 © 2:1 © 2:2 © 2:3 © X4, ■ ■ ■ 

x It is possible to do without the identity, at the cost of 
slightly complicating the code. 






which can be obtained by shifting our partial answer one 
place to the right and adding xo, *2, £4, • • •• We can express 
this idea directly in our notation: 

scan :: (a —> a —> a) —» a —»• Horn a a 
scan (®) b = id proc (x, y) —> do 

y' <- scan (®) b —< x ® y 
yl <— rsh b —< y' 
retumA —< (yl ® x, y') 

The auxiliary arrow rsh b shifts each element in the tree 
one place to the right, placing b in the now-vacant leftmost 
position, and discarding the old rightmost element. This 
could be supplied as a primitive, but it is also possible to 
code it directly: 

rsh :: a —> Horn a a 
rsh b = const b :&: proc (x, y) —> do 
yl <— rsh b —< y 
retumA —< (yl, x) 


Butterfly Circuits. In many divide-and-conquer schemes, 
one recursive call processes the odd-numbered elements and 
the other processes the even ones [14]: 

butterfly :: (Pair a —> Pair a) —> Horn a a 
butterfly f = id :&: proc (x, y) —> do 

x' <— butterfly f —< x 
y' <— butterfly f —< y 
retumA —< / (x', y') 

The recursive calls operate on halves of the original tree, so 
the recursion is well-defined. (The Fast Fourier Transform 
has a similar structure.) Some examples of butterflies: 

rev = butterfly swap 

unriffle :: Horn (Pair a) (Pair a) 
unriffle = butterfly transpose 

Batcher’s ingenious sorter for bitonic sequences [1] is another 
example of a butterfly circuit: 

bisort :: Ord a => Horn a a 
bisort = butterfly cmp 

where cmp (x, y) = (min x y, max x y) 

This can be used (with rev) as the merge phase of a sorting 
function. 

5. RECURSION 

Since arrows are Haskell values, they may be recursively 
defined in the usual way, as we have seen. A different kind 
of recursion involves recursive definition of values within a 
computation, where an output is used as an input. To ex¬ 
press this, we will define a feedback operator on arrows, 
though not all arrows will have such an operator. We ex¬ 
pect that it would generalize the fixed point operator on 
monads, which has signature 

class Monad m => MonadFix m where 
mfix :: (a —> m a) —> m a 


An axiomatization of this operator is given by Erkok and 
Launchbury [8]. Not all monads have such an operator, 
but several important ones do, including state transformers, 
readers, writers and Haskell’s built-in monads ST and 10. 

The straightforward generalization of mfix would be the 

class Arrow a => ArrowFix a where 
fixA ■.:a(b,c)c^ab c 

This could work, but it is neater to separate the output from 
the feedback data, giving the more symmetrical definition 

class Arrow a =4> ArrowLoop a where 
loop :: a (b, d) (c,d) ^ ab c 

The trivial arrow type has such an operator: 

instance ArrowLoop (—>) where 
loop = simple Joop 

simpleJoop :: ((b, d) —* (c, d)) —> b —> c 

simpledoop f b = c where~(c, d) = f (b, d) 

Monads with mfix give rise to Kleisli arrows with a loop 
operator: 

instance MonadFix m => 

ArrowLoop (Kleisli m) where 
loop (K f) = K (UftM fst ■ mfix • /') 
where f x y = f (x, snd y) 

We shall require that the loop operator satisfy the equa¬ 
tions of Figure 7. These axioms are also presented in a 
graphical form in Figure 8. Here the ovals represent loop 
operators, which feed part of the output of the arrow inside 
back to its input. 

Our intent, as with mfix, is that a value is recursively 
defined, but the computation is executed only once. Thus 
computations at the start or end that are independent of 
the recursively defined value can by moved out of loop, us¬ 
ing the tightening rules. On the other hand, the sliding rule 
can move only pure computations on the recursively defined 
value from the end of the loop to the start; moving gen¬ 
eral computations would change the order of computational 
effects. The vanishing rule states that nested recursive defi¬ 
nitions are equivalent to simultaneous recursive definitions. 
Superposing adds unrelated data to the recursion. Finally, 
we require that loop should extend simpleJoop. 

Instances of loop for specific arrows may well satisfy ad¬ 
ditional axioms. For example, effect-free synchronous cir¬ 
cuits would satisfy a stronger version of the sliding axiom, 
in which arbitrary circuits could be moved around the loop. 

5.1 Theoretical Aside 

The simpleJoop operator is an example of a trace oper¬ 
ator, as defined by Joyal, Street and Verity [16, 10]. Their 
definition assumed a braided monoidal category (a relax¬ 
ation of a symmetric monoidal category). The equations of 
Figure 7 generalize their axioms to Freyd-categories, and the 
names of all but the last are taken from the corresponding 
trace axioms. 

In this setting, loop defines a family of functions 
C(B k D,Ck D)^C(B,C) 

Then the tightening rules amount to naturality in B and C, 
while sliding specifies dinaturality in D. 




Left tightening 

Right tightening 

Sliding 

Vanishing 

Superposing 

Extension 


loop (first h^> /) 
loop (f first h) 
loop (f arr (id x k)) 
loop (loop }) 
second (loop f) 
loop (arr f) 


h ;g> loop f 
loop f h 

loop (arr (id x k) ;§> /) 

loop (arr assoc -1 arr assoc ) 

loop (arr assoc second f arr assoc -1 ) 

arr (simple Joop f) 


Figure 7: Loop equations 



Figure 8: Loop equations in graphical form 


It is straightforward to further generalize the signature of 
loop and these axioms to any symmetric notion of compu¬ 
tation. Indeed the Fudgets stream processor library [5] al¬ 
ready includes a version of loop based on sums rather than 
products. 

5.2 Comparison with infix 

Our axioms, restricted to the special case of Kleisli ar¬ 
rows, may be compared to the axiomatization of mfix given 
by Erkok and Launchbury [8]. The three axioms they pos¬ 
tulate correspond to our extension, left tightening and van¬ 
ishing axioms respectively. They reject a possible law cor¬ 
responding to right tightening, because it fails for certain 
monads, the most important of which are those involving 
exceptions. Parametricity of mfix implies a weaker form of 
the sliding law, in which k must be strict, and this proves 
to be necessary for the exception monads. They suggest 
that a slightly stronger version of parametricity holds for all 
monads of interest; this would imply a counterpart of the 
superposing law. 

It may be that a similar relaxation would be desirable in 
the arrow context. For example, a loop operator on parser 
arrows could be used to pass attributes between parsers in 
either direction. (The parsers themselves are values of arrow 
type, and would be recursively defined using the ordinary 
recursion of Haskell.) However, such a loop operator would 
not satisfy the right tightening axiom, because the compu¬ 
tation h might cause the parse to fail, which would make the 
attributes undefined if h were inside the loop. Similarly the 


sliding axiom would fail for non-strict k, if the parse inside 
the loop were to fail. 

5.3 Extending the do-notation 

We could use the loop operator directly, but is is more 
convenient to add recursive bindings to our do-notation, 
as foreshadowed in Figure 5. We use a form modelled on 
the recursive let (O’Haskell [23] has a similar notation for 
monadic do), rather than the recursive do of Erkok and 
Launchbury. This form is more flexible, and has a simple 
correspondence to loop, given by the following translation 

do {rec A; B} = do pB <— form loop (k pA — > do 
A 

return A —< (pA,pB)) 

B 

where pA is a pattern containing those variables defined in 
A that are required in A, and pB is a pattern containing 
those variables defined in A that are required in B. 

6. EXAMPLE: SYNCHRONOUS CIRCUITS 

A synchronous circuit receives an input and produces an 
output on each tick of some global clock. The output for 
a given tick may depend on the input for that tick, as well 
as previous inputs. Such circuits fit well with the data-flow 
model of computation, and several languages of that type 
have been used to model them [2, 6, 29]. 




Consider the following simple circuit (taken from [20]): 



This circuit represents a resettable counter, taking a Boolean 
input and producing an integer output, which will be the 
number of clock ticks since the input was last True. To 
achieve this, the output is incremented and fed back, delayed 
by one clock cycle. The first output of the DELAY component 
is its argument, here 0; its second output is its first input, 

Hardware description languages embedded in Haskell can 
achieve considerable flexibility by parameterizing descrip¬ 
tions over type classes. The microarchitecture design lan¬ 
guage Hawk [20] abstracts over the type of values that may 
pass through wires. Low-level descriptions deal with bits 
(Bool), but any Haskell type may be used, allowing Hawk 
to scale to much more abstract descriptions, and also allow¬ 
ing the same circuit description to be simulated or symboli¬ 
cally executed. Further interpretations are possible with the 
hardware description language Lava [3], where circuits have 
the form 

Value —* Monad Value 

where both value and monad types are parameters described 
by Haskell classes. By selecting appropriate instances, a 
single description may be simulated, symbolically executed 
or presented in a variety of styles 2 . 

6.1 A Circuit Class 

We propose to generalize, treating circuits as arrows, so 
that a wider range of interpretations will be possible. It 
suffices to consider circuits with a single input and output, 
because multiple inputs may be treated as input of a tuple, 
and similarly for output. 

• The arr operation defines circuits where each output is 
a pure function of the corresponding input (e.g. COND 
and incr in the above circuit). 

• Composition connects the output of the first circuit to 
the input of the second. 

• The first operation channels part of the input to a 
subcircuit, with the rest copied directly to the output. 

As usual, we shall require additional operations. We define 
circuits as arrows that support cycles and a delay arrow: 

class ArrowLoop a => ArrowCircuit a where 
delay :: b —> a b b 

The argument supplies the initial output; subsequent out¬ 
puts are copied from the input of the previous tick. A circuit 
built with loop must include a delay somewhere on its second 
input before using it, as in the example above. One could 

2 The most recent release of Lava has however removed mon¬ 
ads from the language, partly by pushing impure features 
into their variant of Haskell. 


newtype SeqMap b c = SM (Seq b —► Seq c) 

instance Arrow SeqMap where 
arr f = SM (mapSeq J) 

SM J^> SM g = SM (g ■ f) 
first (SM f) = 

SM (zipSeq • (f x id) ■ zipSeq -1 ) 

instance ArrowLoop SeqMap where 
loop (SM f) = 

SM (simpleJoop (zipSeq -1 ■ f ■ zipSeq)) 

instance ArrowCircuit SeqMap where 
delay x = SM (Cons x) 


Figure 9: A circuit arrow type 


enforce this by combining the two in a single construct, but 
the present formulation is better suited to algebraic manip¬ 
ulation. 

Here is the resettable counter circuit in arrow notation: 

counter :: ArrowCircuit a => a Bool Int 
counter = proc reset —* do 

rec next <— delay 0 —< out + 1 
out <— retumA —< 

if reset then 0 else next 
retumA —< out 

This corresponds rather directly to the graphical presenta¬ 
tion given earlier. The variables denote the values passing 
through wires on a particular clock tick. 

6.2 Interpretations 

One implementation uses an idea introduced by Kahn [17]: 
components define functions from infinite sequences of in¬ 
puts to infinite sequences of outputs. This idea is the basis 
for several data-flow languages [2, 6, 29], for which hardware 
simulation is just one application, as well as the microarchi¬ 
tecture design language Hawk mentioned above. 

Infinite sequences may be modelled in Haskell by defining 

data Seq a = Cons a (Seq a) 

A circuit description in Hawk consists of a simultaneous re¬ 
cursive definition of several such sequences (there called sig¬ 
nals), each representing the entire sequence of values that 
pass through a particular wire over time. We can use this 
idea to define a circuit arrow type as in Figure 9. The defi¬ 
nitions use the obvious functions 

mapSeq :: (a —> b) —* Seq a —* Seq b 
zipSeq :: (Seq a, Seq b) — > Seq (a, b) 
zipSeq -1 :: Seq (a, b) —> (Seq a, Seq b) 

The underlying model is the same as in Hawk, but program¬ 
ming with arrows has a different feel. In Hawk one works 
with circuits and wires, with variables denoting the entire 
history of wires. Each primitive operation on values must 
be lifted to an operation on sequences, and one often has to 
convert back and forth between tuples of sequences and se¬ 
quences of tuples. In the arrow formulation, one works with 
circuits and values. The conversions are still happening, but 





they are built into the arrow combinators, and thus hidden 
by the arrow notation. 

Other implementations of the ArrowCircuit class are pos¬ 
sible. Instead of maps of sequences, we could use automata 
that map an input to an output and a new circuit, as follows: 

newtype Auto b c = A (b —> (c, Auto b c)) 

The external behaviour is the same, but this interpretation 
may have different operational characteristics. 

We can define further implementations, and thus addi¬ 
tional interpretations, by two strategies. 

1. We can generalize the types SeqMap and Auto, replac¬ 
ing the function type with an arrow parameter, so that 
they become arrow transformers that may be applied 
to any arrow type that provides loop, such as state 
transformers. 

2. Alternatively, we can apply other arrow transformers 
to an existing circuit arrow type to create a new one 
with additional features. 

For example, to add debugging probes to circuits, we define 

class ArrowCircuit a => ProbedCircuit a where 
probe :: Show b => String —> a b () 
so we can extend the counter example 

counter :: ProbedCircuit a => a Bool Int 
counter = proc reset —> do 

rec probe "Reset" —< reset 
next <— delay 0 —< out + 1 
out <— retumA —< 

if reset then 0 else next 
probe "Output" —< out 
retumA —< out 

The intention is that when this circuit is run, the sequence 
of values passing through the named wires will be recorded. 
Achieving this in Hawk seems to require non-declarative ex¬ 
tensions to Haskell [20]. 

In the arrow setting, we can use the second technique 
above, defining a Writer arrow transformer that adds out¬ 
put to any arrow, and indeed preserves all the ArrowCircuit 
structure, as in Figure 10. (We have used the Haskell string 
output type ShowS, but this is easily generalized to any 
monoid). The simulator may then pick off the probe output 
from the circuit outputs. 

6.3 Conditionals 

All the interpretations considered above are also instances 
of ArrowChoice. For example, here is an instance for the 
SeqMap type: 

instance ArrowChoice SeqMap where 
left (SM f) = 

SM (A xs —> replace xs (/ (getLeft xs))) 

getLeft:: Seq (Either a b) —> Seq a 

getLeft (Cons (Left x) xs) == Cons x (getLeft xs) 

getLeft (Cons (Right _) xs) = getLeft xs 

replace :: Seq (Either a b) —* Seq c —> Seq (Either c b) 
replace (Cons (Left _) xs)~{Cons y ys) = 

Cons (Left y) (replace xs ys) 
replace (Cons (Right x) xs) ys = 

Cons (Right x) (replace xs ys) 


newtype Writer a b c = W (a b (c, ShowS)) 

instance Arrow a => Arrow (Writer a) where 
arrf=W(arr (Ax -► (/ x, id))) 
Wf^>Wg=W (proc x -> do 
{y,sl) <-/ —< x 
(z, s2) <— g y 
retumA —< ( z, si ■ s2)) 
first ( Wf)=W (proc (x, y) -> do 
(x',s) <-/ —< x 
retumA —< ((x 1 , y), s)) 

instance ArrowLoop a =4> 

ArrowLoop (Writer a) where 
loop {W f)= W (proc b -> do 
recT(c, d), *)<-/-< ( b, d) 
retumA —< (c, s)) 

instance ArrowCircuit a => 

ArrowCircuit (Writer a) where 
delay x = W (delay x Ml arr (const id)) 

write :: Arrow a => Writer a ShowS () 

write = W {arr (As —> ((), s))) 

instance ArrowCircuit a 

ProbedCircuit (Writer a) where 
probe label = proc x —f 

write —< showString label- 
show String " |_J = U " • 
shows x ■ showChar ’\n’ 


Figure 10: Adding output to an arrow 


The subsequence of inputs tagged with Left is extracted by 
getLeft and fed to the subcircuit /. The outputs of / are 
then tagged with Left and merged with the original sequence 
by replace, replacing the corresponding inputs. The effect is 
to conditionally propagate the clock to subcircuits, as with 
the when construct of Lustre [6]. 

For arrows in ArrowChoice, we can define conditional 
commands as follows (case commands may be defined sim- 

proc p — > if e then ci else oi = 

arr (A p —> if e then Left p else Right p) 

(proc p ci) HI (proc p -*• c 2 ) 

A circuit inside an if-then-else command only takes an 
input and produces an output on clock ticks for which the 
condition is true. For example, the command 

if b then counter —< reset 
else counter —< reset 

is not equivalent to counter —< reset, because it maintains 
two counters, only one of which is reset or incremented on 
each clock tick (depending on the value of b on that tick). 

7. CONCLUSION 

Arrow types, as defined by Hughes, or the equivalent 
Freyd-categories defined by Power and Thielecke, provide 
useful expressiveness beyond that of monads. We have shown 





how a simple and useful arrow-based sublanguage may be 
embedded in the functional language Haskell. As with the 
monadic style, we can use the full machinery of the host 
language in defining new operators, and thus defining new 
sublanguages. We have explored three examples here, but 
expect that many existing DSLs could be simplified and 
strengthened by being recast in this form. 
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